MySQL InnoDB RR隔离级别是否能够避免幻读？

在MySQL的InnoDB引擎中，支持四种事务隔离级别，分别如下：

1、READ UNCOMMITED（未提交读）：使用查询语句不会加锁，允许脏读，也就是可能读取到其他会话中未提交事务修改的数据。

2、READ COMMITED（提交读）：只能读取到已经提交的数据，只对记录加记录锁，而不会在记录之间加间隙锁，所以允许新的记录插入到被锁定记录的附近，所以再多次使用查询语句时，可能得到不同的结果（Non-Repeatable Read）。

3、REPEATABLE READ（可重复读）：多次读取同一范围的数据会返回第一次查询的快照，不会返回不同的数据行，但是可能发生"幻读（Phantom Read）?? "。

4、SERIALIZABLE（串行读）：完全串行化的读，每次读都需要获得表级共享锁，读写相互都会阻塞。

下面对上面四种隔离级别进行简单的举例说明：

1、未提交读：也可以叫做脏读，就是指当一个事务正在访问数据，并且对数据进行了修改，而这种修改还没有提交到数据库中，这时，另外一个事务也访问这个数据，然后使用了这个数据。

2、提交读：也可以叫做不可重复读，是指在一个事务内，多次读同一数据。在这个事务还没有结束时，另外一个事务也访问该同一数据。那么，在第一个事务中的两次读数据之间，由于第二个事务的修改，那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的，因此称为是不可重复读。

3、可重复读：第一个事务对一个表中的数据进行了修改，这种修改涉及到表中的全部数据行。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入一行新数据。那么，以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行，就好象发生了幻觉一样。

4、串行读：这个比较好理解，即独占锁，读写都会阻塞，会大大降低并发量。

在InnoDB中，默认的事务隔离级别是RR（REPEATABLE READ），对于RR隔离级别是否能够阻止幻读，网上的文章有很多的争论，本篇，我们就这个问题进行展开，来聊一下RR隔离级别是否能够避免幻读。

网上的很多博客中，都说InnoDB的RR事务隔离级别中，使用了MVCC机制来避免了幻读，我们下面来做几个实验，同时结合官方文档的说法，来进行验证。

实验环境：MySQL8.0，事务隔离级别：RR

创建一张测试表：

两个事务A、B，RR隔离级别下的快照读，出现“幻读”。

我们开启两个事务Session，在SessionA中进行查询操作，此时没有记录；

在SessionB中进行新增记录，并提交；

在SessionA中再次进行查询操作，并没有查询到SessionB的插入记录；

在SessionA中尝试插入同样主键的记录，发现该记录已经存在，仿佛出现了“幻觉”。

两个事务A、B，RR隔离级别下的快照读，更新时发生"幻读"。 本事务中第一次读取出一行，做了一次更新后，另一个事务里提交的数据就出现了。也可以看做是一种幻读。

我们开启两个事务Session，在SessionA中进行查询操作，此时没有记录；

在SessionB中进行新增记录，并提交；

在SessionA中再次进行查询操作，并没有查询到SessionB的插入记录；

在SessionA中尝试做了一次更新后，SessionB里提交的数据就出现了，也可以看做是一种幻读。

经过上面的两个实验，我们发现在InnoDB的RR隔离级别场景下，是可能出现"幻读"的情况，那么我们界定的幻读，是否与MySQL定义的"幻读"是同一个概念呢？

我们来看一下官方对幻读(phantom)的定义： https://dev.mysql.com/doc/refman/8.0/en/innodb-next-key-locking.html

MySQL官方对幻读(phantom)的定义是：如果在一个事务中，在不同的时间执行查询返回的结果不同，则称为幻读(phantom)。

由此发现，上述实验中，我们认为的"幻读"，对于MySQL来说，并非"幻读"，而是快照读。

https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html

根据官方文档的说法，在RR事务隔离级别下，在当前读的场景下，在搜索和扫描索引的时候使用的next-key locks可以避免幻读(phantom)。

由此我们可以得到结论：

在InnoDB的RR隔离级别中，有两种读，非常容易混淆，我们来拆解一下。

默认的情况下，我们叫它快照读 (snapshot read)，而读取数据库当前版本数据的方式，叫当前读 (current read)。很显然，在MVCC中：

快照读：就是select select * from table ….;

当前读：特殊的读操作，插入/更新/删除操作，属于当前读，处理的都是当前的数据，需要加锁。 select * from table where ? lock in share mode; select * from table where ? for update; insert; update ; delete;

经过上述的解读，我们知道InnoDB的RR隔离级别下，在当前读的场景下，通过加next-key locks来避免幻读。

那么什么是next-key locks？

我们看一下官方文档给出的解释：

简单来说，next-key locks是一种间隙锁，相较于行锁只锁定一行，它会锁定一个区间范围，加锁的范围区间内的索引键值会被锁定，其使用方式如下：

SELECT * FROM child WHERE id > 100 FOR UPDATE;

这样，InnoDB会给id大于100的行（假如child表里有一行id为102），以及100-102，102+的gap都加上锁。

需要注意的是，当加入FOR UPDATE语句后，则从快照读变为了当前读。

了解了next-key locks的定义和使用方式，我们再来做两个实验验证一下是否是这样子的。

两个事务A、B，RR隔离级别下，启用间隙锁。 可以看到，我们对id